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I. DESCRIPTION 

A. Initiative Background 

A new consumer bank infrastructure (Second Summit) is being developed that is targeted to 
provide differentiated services to our customers and improve the customer experience. 

B. Current Environment 

The traditional ATM technology has a number of significant obstacles preventing its ability to 
provide customer differentiation. These drawbacks include: an "old fashioned" screen 
presentation, limited banking functions, and a generic customer interface. The technology can 
only support limited differentiation based upon information contained on the debit card. Today 
the ATM technology can not effectively: 

• Differentiate the customer by customizing their interaction with the bank based upon who 
they are 

• Target specific advertising to a segment of customers or an individual customer 

• Present our brand at the ATM channel in a way that clearly differentiates Bank of America 
from the rest of the industry 

C. Future Environment 

The Web ATM provides the ability to interact with the new "Model 11" infrastructure to deliver a 
screen presentation that is personalized to the customer using the ATM. Over time this will 
include: 

• the ability to implicitly determine which language to display on the screen 

• dynamically adjusting the customer interaction based upon their preferences (e.g. default 
transaction, font size, voice, ...) 

• a faster, easier deposit screen flow 

• which set of differentiated services to provide 

• reinforcing marketing offers for products that the customer has been pre-approved for 

• targeted advertising to customers based upon their demographics 

• the sale of new products to customers (e.g. telephone time, theatre tickets, etc.) 

• messaging status of bank contact and fulfillment to the customer 

Additionally, this technology better positions the bank to support a consistent customer 
experience across delivery channels through the reuse of business logic and customer presentation 
style. 

D. Benefits and Justification 

The benefits of this effort are: 

• Provide an improved customer experience by "personalizing" the screen to the customer 
instead of to the ATM 

• Improve customer service by aligning the customer experience across delivery channels 

• Deepen our customer relationships by selling new products at the ATM delivery channel 

• Provide access to new revenue generating products and services 
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• Leverage the infrastructure costs across multiple channels through the reuse of customer 
presentation and business logic 

• Reduce application development costs and improve time to market by using WEB based 
technology 

• Align Bank of America's ATM Application and Network with the ATM vendor's latest 
hardware and software implementation so that we will be able to take full advantage of the 
new functionality going into the future. 

The business justification for the Web ATM project is being developed by Debit, ATM & Smart 
Card; ST&IPS; IS&S; ATM Channel Management; and Systems Support. The following is a 
summary of that business case: 

• NPV Range of $1 OOMM to $250MM based upon a 5 year investment period using a 1 5% 
discount rate 

• Revenue Drivers: Enhanced service fees, external advertising income, income associated with 
internal advertisements and non-Bank customer fees 

• Expense Drivers: Hardware upgrades, marketing, technology implementation and application 
development. 

E. Implementation Approach 

This project will be implemented in phases as follows: 

• Pilot -May 2000 

This phase will implement the infrastructure to support the Web ATM. The functionality will be 
placed on approximately 44-20= ATMs in either the Florida and/or Southwest market. Both NCR 
and Diebold devices will be represented in the Pilot. The business function will include all 
traditional ATM transactions, customer differentiated marketing and customer segment 
recognition. 

• Pilot Phase II - TBD 2000 

This phase will expand the presence of the Web ATM in either the Florida and/or Southwest 
market up to 100 ATMs and will implement additional business function. The scope of Phase II 
will be determined once the effort has been sized. 

• Rollout -TBD 2001 "2002 

The rollout approach has not yet been determined. The major factors surrounding the rollout 
include: 

• the completion of the TCP/IP based router network rollout along with the direct-attached 
ATM rollout (all markets complete by 2001) 

• the determination of which ATMs will be targeted for upgrade and 

• the successful completion of the Pilot, 
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II. BUSINESS SCOPE 
A. Overview 

The following business requirement section defines those functions that must be delivered as part 
of the initial production Pilot. Requirements for future project phases are not included. 



B. Business Requirements 





Requirement 


Category 


1.0 


Hardware 




1.1 


The Web ATM will be a full function, depository ATM that provides existing 
function as well as new intranet services for active ATM or 24-Hour/Check Card 
customers 




1 1 


TVif^ \kl(^\\ ATM Pilot will iitili-yp Kofh HiphrklH nnH "MPR AT\4q 

1 ne weo r\ i ivi r not wiii uiiiize ooin l/icdoiu ctnu inv-'Iv /a i ivia. 




1.3 


The ATMs will use the following hardware/software: 
Hardware: 

jrrovniG iy\^M\ iinu uicuoiu uciuiiy jrum iijivi spt^L* 
Software: 

• iviicroson / in i v_/peraiing oysicrn 

• iviicrosou iniernei oxpiorcr 

• iDivi weo Ai ivi i^ore Appiicaiion 
Features: 

• Animation 

• English and Spanish 

• Unique ATM signage 

• Audio on Thank You screen and supported for certain ad$ 




1.4 


For security issues and customer service reasons, the ATM should contain a tactile 
keypad (the current function keys will be used as opposed to implementing a touch 
screen). 




1.5 


The ATM will meet all hardware, network security, and Y2K requirements as well as 
be certified as meeting ANSI security requirements. 




1.6 


The ATMs will be alarmed 




2.0 


ATM Transactions 




2.1 


The ATM will offer transactions in English and Spanish. All other languages 
currently in production, will not be supported (e.g. Chinese and French) 
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2.2 


The pilot Web ATM will oflfer the supported Model proprietary transactions: 






• Transfers 






• Checking to Saving 






• Saving to Checking 






• Checking to Checking 






• Savings to Savings 






• Line of Credit to Checking 






• Line of Credit to Savings 






• Credit Card to Checking (not until 0(aft.erJ)0.2) 






• Credit Card to Savings (not until 0(.afeLQ0.2) 






• Cash Withdrawal 






• Checking 






• Savings 






• Line of Credit 






• Cash Advance 






• VISA (not until 0(.afterJ30.2) 






• Master Card (not until 0(aftgjJ)0.2) 






• Fast Cash 






• Full Statement 






• Savings 






• Checking 






• Mini-Statement 






• Savings 






• Checking 






• Deposit 






• Savings 






• Checking 






• Payments Enclosed 






• Electronic Payment 






• Checking to Line of Credit 






• Savings to Line of Credit 






• Checking to Credit Card (not until 0(aft.erjl0.2) 






• Savings to Credit Card (not until 0(afteri)0.2) 






© Balance Inquiry 






• Checking 






• Savings 






• VISA (not until 0(afterJ[)0.2) 






• MasterCard (not until 0afterJ)0.2) 






• Line of Credit 






• Message to bank 




2.3 


The ATM will offer the following acquirer transactions 






• Cash Withdrawal and Cash Advance 






• Fast Cash 






• Balance Inquiry 






• Transfer 




2.4 


New components must support the current stand-in processing for host outages. 




3.0 


Screens 
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3.1 


The ATM will use new graphic screens. 




3.2 


HTML pages will be created and used for presentation 




3.2.1 


Separate HTML screens will be created for each ATM transaction. New HTML 
screens will be created for any new transactions not currently supported by the 
BASE24 application 




3.3 


The actual transaction screen flow and BASE24 mapping for all functions must stay 
consistent witn trie r5Aob/4 mappmg or trie i5anK ot America Mooei a i ivis, 
including the receipt option. They are described in section IV of this document. The 
oniy uirierenccs in inc now are. r ) me r in anci L/dnguage oeieciiuri luriLiiuiia iiave 
been combined into one screen; 2) the Main Menu now has a page 2, and the Check 
Re-order/Message Bank option was moved there; 3) the "Another Transaction " 
screen win conidin me same aauiiionai weu opiiuria da on pdgc z, ui iiic ividiii ivicuu. 






v^reaie a new loau image lor me weo /\ i ivi lo idKe duvdiudge or iiic n i iviij bcrccn 
flow capabilities 




3.5 


The maintenance and management of the new screens will need to be supported. Part 
OT inis erion win mciuue Keeping me iviouei /\ i ivi screens driu bidieis in sync wiin me 
Web HTML screens and 912 emulator. 






^usioiner uiiiereniimion 




A 1 


use ine cusiomer segment ^^Dasic, Associdie, nign vdiue, riua, rremicr, dnu rnvdiej, 
to differentiate the user interface "look and feel". This differentiation can use color, 
icons or graphics to indicate segment. 




A 1 


rersondiize ine inierdciion wiin inc cuDiomcr uy pubiioiy usiiig uicir iidiiic iii iiie 
ATM dialog. (Needs further discussion.) 




5.0 


Marketing 




J. 1 


onow aavenising lo speciric largeiea customers uasea upon preaeiinea marKciing 
data. These ads will target specific individuals based upon the debit card account 
numoer. 




5.2 


Show targeted advertising to an entire segment of customers (Basic, Associate, High 
Value, Plus, Premier, and Private). Additionally, support two segments of acquired 
customers (Basic and Targeted). Targeted acquired customers are recognized by BIN 




5.3 


Support the ability to vary segmented advertisements based upon the geographic 
location of the ATM. 




5.4 


When the customer dialog includes multiple transactions vary the advertising 
presented to the customer. The sequence should be to show any ad targeted for the 
inoiviuuai, roiiowea oy aus lor me cusiomer segment witnm tne /\ i ivis geograpnic 
location, followed by ads for the customer segment, followed by the default ad for the 
system. The system should support the sequencing of multiple ads within a customer 
dialog. 




c c 

J.J 


Provide default ads for proprietary and acquired customers in the event that customer 
inrormation ano airrerentiatea aus are not dvaiiauie. 




J.O 


rrovioe tne aoiiiiy tor tne customer to request contact irom me odUK lor speciiic 
iindiicidi prouuci iiiioriiidiioii. i iiv iiiidiicidi piouucio lo uc auppoiicu win 
determined as the nroiect nroffresses The follow ud contact can be via ohone e-mail 
US mail or banking center appointment. 




5.7 


Ad campaigns will have start and end dates 




5.8 


Support showing both a main advertisement as well as a teaser ad on the screen. 




5.9 


Ads will be in the language specified by the customer at PIN entry time. 




5.10 


Ads for the Pilot will only be Bank internal ads, not external ads. 
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5.11 


Customer-targeted marketing would not begin prior to the Main Selection screen, to 

qHaw timp fnr pamnaicin inFormatinn Xcs Kp Hiiilt If it not returned in time the 
dllvW lllfiv uaiiiuaigi 1 1 1 11 1 1 luiiui 1 wj L/uiii. ii ii lo iivv ivtuiiivu iii iiiiiw, iiiw 

targeted marketing will be put off until the "please wait" screen. 




6.0 


Transaction Record 




0. 1 


1 nc /\ 1 ivi irdnbaLiiuii rccuiuo win uc prcociiicu iii iiic language a|jcL/iiicu uy mc 

r'lictrvmpr 5»nH mirrr\r the Ranlf of Amerifji ATIVI trfin^flrtinn rerrirn cnntammp all 
wUblv/lllCI allU 111111 \j\ lll^ uailiv \ji rAiiid \\^<x fx 1 ivi ii ciiiociviiv/ii i vvv.'i vwiiiaii iiii^ ctii 

pertinent Reg. E data (if applicable) 




6.2 


Support printing marketing data on the ATM receipt based upon customer segment 
(Basic, Associate, High Value, Plus, Premier, and Private). Additionally, support two 
segments of acquired (Basic or Targeted). 




7.0 


Balancing and Servicing 




7.1 


The currently supported replenishing and balancing functions will need to be 
supported on the ATM: 

• Balance Terminal 

• Mid-point adjustment 

• Increase Cash 

• Decrease Cash 

• Print mnrhine Qiih-total^ 

• 1 1 nil iiiaviiuiv' oUL/ luiciij 

• f^lpnr r^pnoQitQ/r^arH^ RetaineH 




7 9 
/ .z 


PrnviHp tpphnirian arrecc tn QtanHarH AXM rliafmn^stir. tnols for the Oiebnld and TVfClR 
Hevire*; 




7.3 


Provide electronic journal support for the ATM devices consistent with the functions 
provided in the current ATM environment. 




7 4 


Provide «iiinnnrt for continuous availability during ATM servicinff 




8.0 


Monitoring 




O. 1 


Provide the ahilitv to monitor the Weh ATlVf's teehnoloov 

riUVlUC LllC dUIllLj^ \\J lllVJlIllWl Lll^ VV VI/ 1 IVI O IWI II llJIV/gj' • 






P\ia\/p|/^n o ctatiic hvte for rpnortintx faults at the \\/en ATlVf 




8.3 


Provide the ability for midrange and ANS operations groups to manage the new 

hardware and ^ofiKvare pomnonent^ introdiioed nv the W^en ATlVt nroiect 

lidl U Wdi C dllVJ j\J\ I Wdi \i> VWlll|J*JllVlllD 111 11 VJULlw^U \Jj lllV TT^U r\ 1 iri yji ^^rj wvt 




O .T- 


Attemnt to integrate Weh ATM into current monitorino^ environments wherever 

A\ llVl 1 1 L/ 1 Wj 1 1 llW^l dlt VV w 1/ i\. 1 IVl 111 WJ VUllVllL IIIWIIIIV/IIJI^ VllVllV/lllllVllliJ vti ivi w t WI 

possible so that it does not require additional watch points. 




9.0 


Security 




0 1 


W/pK ATN/I Rc»n1^in(T will nppd to addrpcc cepiiritv i^cnec related to card and PFM 

W CO /\ i IVl DdlllVlllU will lICwU lU dUUiCoo ovCUlllj lodUCo ivldlwu WJ Wdl U diiu i ii^ 

activation and customer transactions 




10.0 


Reporting 




10.1 


The systems will need to provide detailed MIS reporting on the number and types of 
transactions being performed at the ATM. The actual report layout and definitions 
will need to be defined. 




10.2 


All ATM activity being logged. Reporting will reflect any new activity. 
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C. Business Alternatives 

1. Selected Alternative 

Proceed with the development of a Web based ATM infrastructure to provide 

• Differentiated services to the customer 

• Targeted advertising to individuals and customer segments 

• Branded look and feel at the ATM channel 

Additionally, since Web ATMs will not replace ALL of Bank of America's H e ritQ^ e Traditional 
ATMs in the near future, some of the Web ATM's features will be integrated into the 
H e ritQg e Traditional ATM hardware at some point. 

2. Other Alternatives Reviewed 

a) Use current ATM technology 
The use of current ATM technology was considered for delivering differentiated customer 
service, targeted advertising and the brand implementation. However, limitations in the 
technology would significantly hinder our ability to deliver the next generation product. 
Specifically, the use of states/fits in the ATM configuration technology along with the "DOS" 
like user interface is not flexible enough to support all the business needs. 
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3. Operational/Procedural Impacts 



Area/Item Affected Impact 



Banking Centers 


Potential modifications to ATM servicing 
procedures 


Vendors 


Potential modifications to ATM servicing 
procedures 


Marketing 


Changes in process to define and implement 
marketing campaigns on the ATM channel 


Field Service Personnel 


Changes in procedures related to ATM field 
diagnostics to take into account new ATM 
hardware and software 


ATM Network Services 


Changes in nrocedures related to ATM device 
outages due to new ATM hardware and software 


Back Office Departments 


Changes in procedures for fulfillment of Web 
ATM requests 


Tandem Technical Support 


Additional interfaces and technology such as OSS, 
ITP Web Server, and more MQ queues to support. 


ATM Software Development 


New software implementation procedures 


Midrange Operations / Network 
Operations 


New Tandem components to support: 

• TCP/IP ATMs 

• New Web Server environments 

• MQ Series application and queues 


4. Training Impacts 

Area/Item Affected Impact 


Banking Centers 


Training on any modifications to ATM servicing 
procedures 


Vendors 


Training on any modifications to ATM servicing 
procedures 


Field Service Personnel 


Training related to ATM field diagnostics to take 
into account new ATM hardware and software 


ATM Network Services 


Training on any procedure changes related to ATM 
device outages due to new ATM hardware and 
soflAvare 


Back Office Departments 


Training related to changes in fulfillment 
procedures 


Tandem Technical Support 


Training necessary to support the installation and 
maintenance of the new interfaces and technology. 


ATM Software Development 


Training on all of the new software technology 
being used. 


Call Centers 


Training related to handling new disputes, etc. 


Mid-Range Operations 


Training on any procedure changes to support new 
software components on the TANDEM 
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5. Geographic Impact 



Area/Item Affected Impact 



Florida or the Southwest 


Minimal impact to the 4-9-20 sites that will 
participate in the Pilot Phase 1 and up to 100 sites 
in Phase II. 


6, Customer Impact 

Area/Item Affected Impact 


Florida or the Southwest 


■ Customers who use the ATMs in the Pilot will 
see a new and improved interface at the ATM 
channel. 

■ Additional E-Mail generated when a customer 
requests product/service information at an 
ATM 
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D. Risk Assessment 

Impact on the Approach to Manage or 
Risk Probability business Mitigate Responsibility 



1. 


The new ATM 
technology could 
compromise the 
reliability of the Pilot 
ATMs 


Medium 


Low 


Significant testing will 
be completed prior to 
implementation 


Project 
Initiative 

Team 
Abowd 


2. 


MQ Series/ Service 
Broker/ IMS 

nprfnrmanpp mav not 

L/Vl 1 1 lul 1 w& MlClj \\\J\. 

scale. 


High 


May have to display 
"default" screens if 

customer nrnfile 

information cannot 
be retrieved in a 
timely manner 


Can get Customer 
Segment info from 
Base24 CAP COO H / 
Use default screens 


Fei 


3. 


The IBM Web product 
is unproven technology 


Medium 


Customers will 
experience problems 
at the ATM 


Significant testing. 


IBM/Fei 


4. 


The ITP Web Server is 
new to Bank of 
America technology. 


Low 


Will not be able to 
provide customer 
differentiation 


Use ATM resident 
default screens. 
Significant testing. 


Fei 


5. 


912 emulation may 
constrain our ability to 
simplify the customer 
dialog. 


High 


Would delay 
introduction of 
enhanced features 


Pursue replacement of 
912 emulation with a 
more open interface. 


Fei 

Abowd 


6. 


The use of TCP/IP 
protocol at the ATM 
may introduce new 
security risks. 


Low 


Mav be easier to 
pirate information 
needed to create a 
card. 


Pursue encrvption of 
more than iust the PIN 
for a future phase. 


Fei 
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III. SYSTEMS SCOPE 

A. Proposed Systems Solutions 

The current ATM system is based on the ACI Base24 product and implements proprietary ATM 
vendor message structures over a router-based Frame Relay network using the SNA/SDLC 
communications protocol. The proposed Web ATM product will use this same message interface 
over the same Frame Relay network but will use the TCP/IP communications protocol. The 
current ATM screens will be replaced with browser-displayed HTML pages. All new 
functionality will be implemented using Web Browser/Server technology. 

The sections that follow specify the systems scope for Phase I of the Pilot. 



B. Systems Level Flowchart 
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1. WEB ATM 

The Web ATM will be based on IBM Canada's ATM w/Web Extensions product and will be 
implemented on both Diebold and NCR ATMs using standard WOSA APIs for device control. 
This product runs under Windows NT and employs Browser technology for screen presentation, 
and JavaScript functions to support dynamic HTML pages and new Web application services. 

Model ATM transactions will be supported by the ProCash DDC (Direct Diebold Connect) 912 
emulation software from Siemens Nixdorf with Web extensions that allow the use of HTML 
pages in place of the standard screens contained in the Load Image file. 

The Web Extensions will also provide the ability to put additional options on the DDC menus that 
allow accessing of services and pages from a Web Server. The Web extensions will also allow 
the Web services to access ATM devices such as the keyboard and printer so that they can 
interact with the ATM customer. 

The two pieces of software will communicate via shared memory and event objects supplied by 
IBM designed and written "Core" software. The interactions between the various ATM sub- 
systems are described in more detail in the "III. INTERFACE PROCESSING" section. 
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912 Emulation 


Service 


^ Post 


Provider 


Event Objects 


Modules 


^ Listen 


(SPMS) 


Web 




Browser 





Tandem 
Base24 




Web 
Server 





2. NETWORK ACCESS 

Network Access for the ATM will be through an Ethernet LAN and Cisco Router using TCP/IP. 
The Router will provide gateway services into the fi-ame relay-based Model Digital Network. 

The move to the TCP/IP protocol will implement tunneling and have no impact on Base24 
transaction security. The current DES-based session security will remain as it is and transactions 
will continue to traverse the same trusted Frame Relay network. 
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In the Pilot phase there will be no sensitive information in the Web Server path. Later phases will 
require the addition of customer authentication and a security protocol such as the Secure Sockets 
Layer (SSL). Note. The iTP Secure Web Server's SSL implementation supports 128-bit RC4 
encryption domestically. 
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3. BASE24 

With the initial phase of development it is important to change network protocols, TCP/IP is the 
industry standard protocol for Web based transactions and therefore to fully take advantage of 
developed services the Web ATM should exploit the protocol for access to Base24. 

Web ATMs will generate additional unsolicited status message types if they encounter problems 
related to the Web server path. The Base24 Device Handlers must be modified to recognize and 
parse these new statuses and log appropriate error messages for the ATM Monitoring system(s). 

There are no other planned changes to the Model Base24 system. WEB ATMs will appear as 
Diebold's standard MDS (Modular Delivery System) ATMs using currently supported 912 
messages over TCP/IP protocol. The Web ATM will have a special LOAD IMAGE file that 
contains only states and FlT's. No screens are needed, as the ATM will display HTML pages 
supplied by a Web Server. 

4. Tandem's iTP SECURE WEB SERVER 

The Tandem Web server will provide two main functions: 

• Support URL requests and serve up HTML and Java applets for the supported set of 
transactions 

• Route messages from Web ATM client to the appropriate application server using CG\\ 

The Web Server runs in Tandem's Open System Services (OSS) environment - Tandem's 
environment for portable applications. (OSS is based on the X/OPEN CAE Specifications, which 
implement the POSIX 1 and POSIX 2 standards, and the UNIX KORN shell). Most OSS 
commands and utilities have a direct counterpart in UNIX. Others are unique and provide 
interoperability with the proprietary Guardian environment - very useful if we need to access 
ATM information maintained in Base24 files. 



Note: The iTP Secure Webserver complies fully with: 

• HyperText Transfer Protocol (HTTP/ 1.1) 

• Common Gateway Interface (CGI/1 . 1 ) 

• Secure Sockets Layer (SSL 2.0 and SSL 3.0) 

• Microsoft Private Communications Technology (PCT version 1) protocol 



^ CGI (Common Gateway Interface) is a standard for connecting an application server to a 
Web server. 
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5. APPLICATION SERVERS 



When the Web server receives input from a web client, it may satisly the request by returning a 
requested document (e.g. Web page) or may forward the request to an application program whose 
results are returned to the requesting client. 

Application servers will be written to provide session and transaction integrity, directory and 
gateway services to Web Service providers. They will also provide translation and formatting 
functions between the Web ATM and the service providers, and will manage the configuration 
and monitor the availability of the Web ATM. 

The Application servers will provide the following functions: 

• Route transaction requests to the proper destination and provide any message translation 
necessary 

• Manage the Web ATM session and transactions and perform any recovery and notification as 
necessary 

• Initiate and manage any gateways to servers that provide services for the Web ATM 

• Provide Directory services that define the transactions available at the Web ATM and the 
destinations that can provide those services 

• Monitor the Web ATM and server components and support any network management or 
software distribution requests 

Java will be used wherever possible to support the Model II requirement that code should be re- 
usable/portable as much as possible. These application programs will be implemented as Java 
servlets that receive requests via a CGI interface. They will receive information from the Web 
server through environment variables and standard input, and return dynamically generated Web 
content via standard output. The Web Server is then responsible for returning the information to 
the ATM client. The Servlet Server Class (SSC) allows CGI applications to be written as Java 
servlets. 



The Web ATM application, in conformation with the Model II architecture, will obtain customer 
profile information from the CICS-based Service Broker application via the Bank's MQ Series 
Message Bus, 

The MQ Series software provides application-programming services that enable processes on 
different nodes on a variety of machines and operating system types to communicate with each 
other using message queues. It provides a common API called the Message Queue Interface or 
MQl, so that programs developed on one platform can be readily transferred to another. MQ 
Series takes care of network interfaces, assures delivery, deals with communication protocols, 
and handles recovery after system problems. Both TCP/IP and SNA network protocols are 
supported. The latest Tandem version also adds ICE (Insessions' Intersystem Communication 
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Environment) support. Note: The MQ Series for Tandem was developed by Candle Corporation, 
an IBM Business Partner. 



7. SERVICE BROKER 

The Service Broker receives requests from its Service Request Queue and invokes the appropriate 
script based on the standard header. The Service script contains the bank workflow logic to 
satisfy the client service request. The request is translated into a Legacy request or requests and 
messages are sent across the Message Bus to the appropriate Legacy application(s). The Legacy 
response(s) are then reformatted into a client response in a Standard Message Interface (SMI) 
format. 

The SMI is based on the Business Object Document Model (BOD) from the Open Applications 
Group. The Business Object Document (BOD) is used to communicate a request from a 
requesting application to a destination business application (such as the service Broker), In turn, 
the destination business application returns a Business Object Document response. 

Each BOD is a self-defming message that includes all the business details needed by applications 
using the SMI APIs. 

The Standard Message Interface (SMI) allows a calling program to either encode or decode an 
Open Applications Group (OAG) message using a set of API calls. These APIs use a message 
handle to keep track of the state of the encode/decode process for a given message and provide 
consistent return area information about the success of an API call. All of the APIs are also 
available to Java classes through the SMI package that implements a Java Native Interface (JNI) 
to these APIs. 
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C. Areas Affected 

1. System / Technical Summary 



Area/Item Impact 



ATM 


• WOSA Service Provider Modules (Device Drivers) 

• New Browser technology / HTML screens 

• Diebold 9 1 2 emulation for Model transactions 

• Marketing data printing on receipts 

• Additional status messages for thermal printer / Web 
Server problems 

• Electronic Journal support 

• Diagnosis tools 


BASE24 


• TCP/IP protocol support 

• Single PFN & language selection 

• New load image to support Web ATM requirements 

• Support for new device status 

• New Web Server status messages from ATM 


New Tandem Software 


• Open System Services (OSS) 

• iTP Web Server 

• New application servers: 

■ To obtain customer profile information 

■ To select an Ad to display 

■ To administer customer/Ad profile data 

■ To load campaign / card lists 

• To send E-Mails to Customer Support areas 

■ To collect MIS information 

• MQ Series for Tandem 


ATM Monitoring 


New ACI and Tandem TCP/IP components 


GASPER/Thin Monitoring 


New EMS events will be needed to make this possible 


Service Broker 


New MQ Series queues (to/from Tandem) 
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IV. FUNCTIONAL DESIGN 

A. Customer Presentation 

1. General Approach 

Summary 

The initial Pilot Phase of the Web ATM project will: 

• Implement the Bank of America brand using the corporate standards 

• Use customer profile information to 

• Target advertising to an individual or segment of customers 

• Customize the screen background 

• Personalize the dialog with the customer 

• Simplify customer dialog by combining language preference and PIN entry screens 

• Provide new customer service options for Bank product information 



2. Web ATM Screen Zones 

The ATM Consumer Screen w^ill be partitioned into several visual "zones". These 
zones be used for different functions. Responsibility for zone placement is an 
ongoing cooperation between the Systems personnel and the Marketing personnel. 
The following diagram illustrates the current Web ATM screen zones: 



Function Key 
F Label 



Function Key 
G Label 



Function Key 
H Label 



Function Key 
I Label 



Background 



Main Ad 



Dialog 




Input Box 





Barmer Ad (teaser) 



Function Key 
A Label 



Function Key 
B Label 



Function Key 
C Label 



Function Key 
D Label 



• Background - this visual zone extends over the entire consumer screen area and provides 
a context for the other zones. The other zones are overlaid on top of the background. The 
background will contain brand information and logos that represent the corporate image. 
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• Main - this visual zone is centered on the background and is generally used to present 
the major advertising material. Typically this zone will display animated or video "film 
clips". The main ad space can have three different categories of ads: 

• Attract Ads - play when there is no customer using the ATM. Attract ads are 
generally video clips that play in a repeating loop. These ads will not contain 
audio material 

• Targeted Ads - play when there is a customer using the ATM. After the 
customer is identified via the card read, ads that have been specified for this 
customer will be activated. The Targeted ads will play throughout the customer 
session. These ads mav contain audio m aterial. 

• Closer Ads - play at the end of the customer session. Closer ads will be activated 
when the customer has elected to terminate the session These ads will play while 
the customer is retrieving the card, receipt, and any cash or coupons. These ads 
mavj:mtmji.au<lijim^ 

• Banner - this visual zone is centered at the bottom of the screen area. Additional 
advertising material will be played in this zone. This ad space can be used for "Teaser" 
ads that change throughout the session or for "specials" that are specific to that location. 

• Dialog Box - this visual zone contains the customer instructions during the ATM session. 
The customer will be prompted with text displayed in this zone to "select a ftinction" or 
"enter their PIN". 

• Input Box - this visual zone is centered in the middle of the screen and overlays the Main 
Ad zone. The Input box is used whenever customer information is requested from the 
numeric keypad. As customers type numbers from the keypad, they will be displayed in 
the Input Box. Certain privacy elements such as PFN data will be displayed as asterisks. 

• Function Key Labels - in addition to the numeric keypad, the customer will also use the 
ATM function keys to make menu selections or product decisions (same as the current 
traditional ATMs). In order to guide the customer, there can be up to eight of these 
Function Key Labels that correspond to each of the ATM's function keys. As with 
current Base24, the positioning will be based on the ATM screen type. These Labels 
provide the "meaning" of each specific function key. The content of the Function Key 
Labels could change with each interaction with the customer. 

In addition to the screen zones, the customer receipt will also be divided into zones. The 
current content and format on the receipt will be preserved. However, there will be 
advertising space reserved at the top of the receipt. This area is called the Receipt Ad. 
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3, Transaction/Screen Flows 

Representative samples of the proposed Web-Enabled ATM screen flow, based on the Model 
Base24 transaction flow with some modifications, are documented below. Although the 
samples in this document are only in English, Web-Enabled ATMs will support screen dialog 
and advertisements in the customer's language of choice. Two types of Model Base24 
transactions are not included because the user interface will not change for this project: 
Electronic Joumaling and System Administrative (Balance Terminal, Mid-Point Adjustment, 
etc); the 912 Emulator will handle them in the standard way. 

The information is divided by category of screen flow. For the purposes of this document, 
there are three categories of screen flows, where "On-Us" means any Bank of America card 
(jexcjepijcxejliL^^^^ which willJb,eJmpJemcMe-d,aft.e^^^ a Model ATM: 

• Initial and Closing Customer Flows 

• Main Menus 

1. On-Us Menus 

2. Acquirer Menus 

• Specific Transaction Flows 

1. Fast Cash (On-Us) 

2. Cash Withdrawal (On-Us) 

3. Cash Withdrawal (Acquirer) 

4. Deposit (On-Us) 

5. Payment (On-Us) 

6. Transfer (On-Us) 

7. Check Re-order / Message (On-Us) 

8. Request for Product Information (On-Us) 

9. Request for Product Information (Acquirer) 

The Screen Name column lists the major screens and the name by which they are referred. 
The Screen Dialog column lists the fixed text (prompts related to an ATM transaction and 
not to an advertisement), that will be displayed on the screen. The Processing column 
describes the relevant processing that occurs while at the screen. The Available Ad Type 
column lists what types of ads may play while the screen is displayed. The Function Key 
column lists the active function keys for the screen. 

In the Processing section of the screen flow, getting customer information from BOSS is 
mentioned frequently. It is new to the ATM transaction flow, and will provide more 
information than Base24's CAF does. It will also return data that will not be used, such as 
information about accounts that are NOT linked to the customer's ATM card (the customer 
will be given access only to accounts specifically linked to the card). The response time for 
Service Broker to request a customer's profile and receive the reply is currently reported to be 
about two seconds. 

In general, the same Main ad will play throughout an entire transaction, without interruption 
for errors or exceptions. All the various error and exception screens (i.e., "Do you need more 
time for this transaction?") will continue to display the same Main ad as was on the 
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transaction screen where the exception or error occurred. When the transaction is finished the 
ad will end. If the customer starts a new transaction, the same Main ad will start again from 
the top, or, if another ad was defined for this campaign, the next Main ad in the list will start. 
See the Ad Selection Criteria section IV.4 of this document for further details on how ads on 
the screen will work. 
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4. Ad Selection Criteria 

The Web ATM technology marries the two different systems of: 

• State/screen-based technology used between the ATM and the Base24 system, and 

• Client/server-based technology used by the Web ATM and the Web Server. 

Non-Web ATM processing is state based in that the ATM or Host evaluates the current 
screen plus any customer input to determine the next action or the next display to present. 
With the advent of the Web ATM, each time the screen or state changes, we have an 
opportunity to invoke web-type services. The major web-type service we are implementing 
in the first phase involves using the ATM as an advertising billboard. The Web ATM 
administrator will have the ability to define specific ad content that: 

• Positions ads in particular places on the ATM screen 

• Plays ads at specific times before and during a customer session 

• Select specific ads based on certain criteria that is a combination of the ATM, the 
customer, and the currently available content 

The position of an ad is defined by the particular ad type (e.g., teaser ads play in the Banner 
zone). This is defined in section A. 2. Controlling when ads start and stop is based on the 
state of the ATM (e.g., targeted ads start when the main menu is displayed. They stop when 
the transaction is completed). This is defined in section A. 3. This section addresses how 
specific ads are selected. 

The advertising content presented on the Web ATM can be specified at three different levels: 

• Session Based - different ad content can be configured depending on whether or not 
the ATM is in use 

• Customer Based - different ad content can be configured for different customer types 

• Rules Based - overrides can be defined to alter the particular ad selection during a 
session 

a) A TMAd Selection Process 

The Web ATM has two types of advertising "personalities" depending whether or not there is 
a customer session. When there is no card inserted into the ATM, the ATM's personality is 
defined strictly by its "market class". The market class of an ATM is a factor of its 
geography (e.g.. Bay Area), its market location (e.g., In Store-Luckys), and its capabilities 
(e.g., Web ATM). The Market Class personality defines the specific content of the 
Background and Main Ad visual zones. For example, the Background content could be a co- 
branded look when the ATM is in-store. The Attract Ad in the Main Ad zone could be 
playing a regionally targeted ad that varies depending on geography. The Administrators will 
have the ability to configure the Market Class of the ATM and its relationships to advertising 
content. 

After an ATM is brought up, it will query the Web Server. The Web server will: 
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• Retrieve the Market Class of the ATM 

• Use the Market Class to obtain the ad name that has a Background type (this 
association is described in section B) 

• Serve up the graphics file that is specified by that ad name 

• Use the Market Class to obtain the ad that has an Attract ad type 

• Serve up the graphics file that is specified by that ad name 

• Use the Market Class to obtain the ad that has a Teaser ad type 

• Serve up the graphics file that is specified by that ad name 

Those three ad types will continue to play on that ATM until a customer inserts his/her card. 
Whenever the customer session is over (i.e., the card is removed), the Web ATM will begin 
to play the three ad types again. 

If there is more than one ad that satisfies any of the retrievals, the Web Server will invoke 
override processing (see below). If no ad is specified, the default Market Class (i.e., None) 
will be used. These ads will play until a customer session is started. 



b) Customer Ad Selection Process 

Afl:er the customer has been identified, the ATM will change personality based on customer 
information. The goal is to differentiate the customer experience at the ATM based on their 
banking relationship. The Background and advertising content may be tailored to the 
customer. During transaction processing, a customer specific Targeted Ad will play. 
Customer differentiation is based on different criteria. The advertising content for a Bank of 
America customer can be specified at three levels: 

• BofA Card Number - the Web ATM administrator has the ability to define the 
advertising content by specific card number. This is envisioned like a telemarketing 
campaign where specific customers are targeted for specific products 

• Customer Segment - if this customer's card number is not defined on the Web ATM 
database, the customer segment will be used. The customer segment types are Basic, 
Associate, High Value, Plus, Premier, and Private. 

• Default On-Us - if the customer segment is unavailable, the Web ATM will use 
default advertising material. 

For acquired, or not-on-us, customers, the Web ATM supports two levels of differentiation: 

• Card Prefix - Advertising content can be specified by the Bank ID number. For 
example. Wells Fargo or First Union customers can be targeted for specific ad 
content. 

• Acquirer Default - If the card prefix value is not found on the Web ATM database, or 
the card used is a credit card, the Acquirer Default content will be used. 
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The system will determine the customer profile by using the following algorithm: 

1 . If the card is proprietary then a) look up in user-supplied customer lists - if 

found use that value 

b) else get customer segment value - if 
available use segment value 

c) e 1 se u se Proprietary Default 



2. If the card is not-on-us then a) look up in the card prefix database - if found 

use that value 
b) else use Acquired Default 

Once the Customer Profile is known, the Web ATM will use similar processing to select the 
specific ads for play as it used in the Out of Session processing: 

• Use the Customer Profile to obtain the ad name that has a Background ad type (this 
association is described in section B) 

• Serve up the graphics file that is specified by that ad name 

• Use the Customer Profile to obtain the ad name that has a Targeted ad type 

• Serve up the graphics file that is specified by that ad name 

• Use the Customer Profile to obtain the ad name that has a Teaser ad type 

• Serve up the graphics file that is specified by that ad name 

• Use the Customer Profile to obtain the ad name that has a Closer ad type 

• Serve up the graphics file that is specified by that ad name. Note that the closer will not 
be played until the Closer screen is presented. 

• Use the Customer Profile to obtain the ad name that has a Receipt ad type 

• Serve up the graphics file that is specified by that ad name. Note that the receipt ad 
content will not be printed until the Closer screen is presented. 

If there is more than one ad that satisfies any of the retrievals, the Web Server will invoke 
override processing (see below). If no ad is specified, the defaults will be used. These ads 
will play until the customer session is completed. 
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c) Overrides 

There are three different ways the defined advertising selection can be altered dynamically. 
These exclusions only go into affect when there are multiple ads defined for a particular 
customer profile. 

• Priority - When an Ad is defined for a customer or customer segment, it also has a 
relative priority. This priority is used to determine which ad will play. 

• Exclusion - Ads may have assigned product attributes. Such as a Gold Visa ad may 
be assigned the Visa product attribute. The customer product set will be evaluated 
and any ads that the same product attribute as the customer will be excluded from 
play. 

• History - If there are multiple ads defined for this customer, the system will check 
history and play the least viewed ad based on priority. 
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5. Cash Withdrawal and Investment Information Request 

The following screen set illustrates: 

• Acquirer Cash Withdrawal transaction screen flow and 

• Request for Investment Information transaction screen flow 




Attract Loop 
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PIN and 

Language 

Entry 



Acquirer 
Main Menu: 

Transaction 
Selection 



ric:isc t utor your PIN (10 CcKle) 

I hen press this key > 

Desptieile niarcarsu IMN 

(iprima nqui > 
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Bankof America. ^ 



^ ^ . P I e a s r c iit c i- v o ii i- ( cl c p h o i u' ii ii in hiM*. A hunk 
ri'prcsontativo will contact you with the inforniation. 




Xeamn 




Bankof America. 



Amount 
Entry 



Please select an acc4>iint 




Select an 
account 
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-Leading 
the way. J 




Won 111 you like another tninsuction? 




CHOOSE THE CA RD THAT W ORKS FOR YOU. 



S5^ 



Would you 
like another 
transaction? 

Investment 
Info chosen 

Note: The 
format of 
this screen 
will be 
changing 
but the 
general 
content will 
stay the 




Phone 

Number 

Entry 
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Xea¥ing 



Bank of America. 



Would you like another iniiisiictionV 




Would you 
like another 
transaction? 

"No" Chosen 

Note: The 
format of 
this screen 
will be 
changing. 
but the 
general 
content will 
stay the 
same. 




Thanks 



iw» -wti HW. fe^ 



The liunkA met icanl 
l%tsyic CtViJii Can! 
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6. Deposit and Mortgage Information Request 

The following screen set illustrates: 

• On-Us Deposit transaction screen flow and 

• Request for Mortgage Information transaction screen flow 




Attract Loop 
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Bankof America. ^ 



Plciise enter your 1*1 N (il) Coile 
I lien press this key 



> 



Despuctle mareiu su IMN 
oprinm iupii - 



^^^^^^^^^^^^^^^^ 



PIN and 

Language 

Entry 



Bankof America. 



Please seleet a transaction 




On US Main 
Menu: 

Transaction 
Selection 
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Select an 
account 
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Bank of America. 



Woiikl vo" like :» not her tnni suet ion? 
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Ueh*n7 0^ « • fou ioURfUd in tuvinf *tfy 
MCiH to txtt* euh wtuaara youiuid d7 
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card 
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7. Mortgage Information Request Contact E-mail 

The following is an example of the e-mail that will be automatically generated by the 
Mortgage Information Request transaction. Note that information about the product the 
customer was interested in may be attached to the note if the email address the note was 
sent to is accepting requests for information on more than one type of product. 



Bank of America 



From: 

To: 
cc: 



ATMServer on 08/16/99 14:42 
Mort.Marketing@bankofamerica.com 



Subject:ATM Customer Request for Info 

The following customer has requested via ATM to be contacted 
by Bank of America with more information about Mortgages, 



Contact By: 

Customer Name: 

Address: 

City: 

State: 

Zip: 

Phone: 

E-mail: 

Customer Segment: 
Customer Accounts: 



E-mail 

Jack Teagarden 
200 S. College St. 
Charlotte 
NC 

28255-0001 
(704) 388-1234 
Teagarden@aoLcom 

Premier 

12345676890 

10101010101 



Request Date/Time: 
ATM Number: 



08/16/99 14:40 
SNCN9002 
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8. Mortgage Information Request Receipt 

The following is an example of the receipt that will be automaticaUy generated by the 
Mortgage Information Request transaction: 

01234 56789012345678901234 56789012345678901234 5678901234 56789012345678901234567890 
FOR CUSTOMER SERVICE CALL 1-800-333-6262 
USE YOUR ATM OR CHECK CARD AT OVER 14,000 ATMS 

08/23/99 14:39 *OVERSTREET MALL CHARLOTTE NC 
CHECKING WITHDRAWAL $3 00.00 FROM CHECKING 

BALANCE $506,065.92 

SNCD1641 XXXXXXXXXXXX5555 SER. NO. 1234 
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B. Configuring Web ATM Ads 

This section specifies how the administrator configures and coordinates the advertising material 
with the customer experience. There are several functions required to set this up: 

• Campaign Profile Definition - establishing and defining the attributes of a marketing 
campaign 

• Ad Profile Defimition - establishing and defining the attributes and relationships of specific 
graphics files 

• Customer Profile Definition - establishing and defining customer types to the system 

• User Supplied Profile Files - files containing card numbers or prefixes for specific market 
segments of customers 

• Linking Customer Profiles to Ads - establishing the relationships between customer types and 
session-based advertising content 

• Linking Market Classes to Ads - establishing the relationship between specific ATMs and 
non-session based advertising content. 



The following diagram illustrates the Web Server Ad Database: 



Campaign 



Ads 



Link 



•Attract 
•Target 
•Closer 
•Teaser 



ATMs 



Customer 
Profile 



•None 
•Default 
•Segment 
•User Supplied 



User Lists 



KEY = Card Number + Customer Profile 



1. Campaign Profile Definition 

A marketing campaign is the term used to describe a set of advertising content that has been 
targeted to a specific group of customers. A Campaign can reference all types of Ads. 

The fields used in a campaign definition are: 

• Campaign Name - the user provided name for this campaign 

• Description - text that describes this campaign 
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• Effective Start - the date/time that the campaign should be used in production 

• Effective End -the date/time that the campaign should not be used in production 

• Relative Priority - the priority this campaign has relative to other active campaigns. 
This element is used when multiple campaigns are active and the customer or ATM 
qualifies for more than one campaign 



2. Ad Profile Definition 

An ad refers to any advertising content that will be presented to the customer. 
The fields used in an ad profile definition are: 

• Ad Name - the user provided name for this ad 

• Ad Description - text that describes the ad such as content, play time, etc. 

• Ad Type - the type of ad. Types are: 

• Background 

• Attract 

• Targeted 

• Closer 

• Teaser 

• Campaign Associations ~ name(s) of the campaign(s) that this ad should be 
associated with. An ad can belong to one or many different campaigns. The system 
will provide a list box of all active or future campaigns 

• Product Categories - the name(s) of the banking products that this ad should be 
associated with. An ad can be associated to none or many different products. This 
element is used in exclusion processing. 

• File Name - the name of the file containing the ad content 



3. Customer Profile Definition 



Customer profiles are ways to categorize Web ATM users in various ways. The system will 
provide an initial set of customer profiles that correspond to the different customer segment 
values. The administrator will also be able to define special customer profiles by either 
providing a file containing specific card numbers or by providing a file containing Card 
prefix values. 



• Customer Profile ID - the name of this customer profile. The system will provide 
several standard customer profiles 

• Profile Type - defines the processing used by the system. Values are: 

• None - used when there is no customer 

• Proprietary Default - used when BofA customer information is unavailable. 

• Acquired Default - used for not-on-us customers 

• Customer Segment - use the value contained on the CIF (e.g., PLUS) 
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• Market Set - use the Web ATM database of BofA card numbers 

• Card Prefix - use the not-on-us Card prefix database 

4. User-Supplied Customer Lists 

As stated above, the marketing groups can load card numbers or card prefixes into the Web 
ATM database. The user-supplied record contains the following data elements: 

• Card Number or Prefix - the card number or card prefix containing up to 16 numeric 
characters. Acceptable wild cards are % for any number of characters or # for single 
character substitution 

• Customer Profile ID - the user defined customer profile value that matches one 
defined within the Web ATM customer profile database 

• Effective Start Date - the date when the system should use this entry 

• Effective Stop Date - the expiration date of this entry - i.e., when it should be 
removed from the database. 

5. Linking Ads to Customer Profiles 

Once the Ads and the Customer Profiles have been defined to the system, the administrator 
can then make the association between the ad and the customer profile. This is the 
mechanism to define which ads play during a customer session. 

The administrator first selects the particular customer profile. Next the campaign is selected. 
Finally, the linkages between a specific customer profile and a specific ad are made. The 
administrator may select multiple ads for a particular customer profile, but if there are 
multiples, then the administrator must set the relative priority. 

The fields used on this form are: 

• Customer Profile ID - the value of a defined customer profile. The system provides 
a list box of all customer profiles for the user to select. Multiple customer profiles 
may be selected 

• Campaign - the value of a defined campaign. The system provides a list box of the 
valid (i.e., non-expired) campaigns for the user to select. Multiple campaigns can be 
selected, 

• Ad Type - the type (e.g., background, targeted, teaser) of the ad. This is a protected 
field. 

• Ad ID- the ID of the Ad that the user wants to link to this set of customer profiles. 

• Relative Priority - the order this ad should play relative to other ads defined for this 
customer profile and ad type 
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6. Linking Ads to Market Classes 

We also want to be able to define the ads that play when there is no customer session. 
Defining the "attract" ads or "teaser" ads that are presented while the Web ATM is inactive 
uses the same process as linking customers to ads. When ATMs are defined to the system, 
they are also a given "market class". The market class is a way to specify that the ATM has 
specific business arrangement (e.g., Lucky's), has a specific location (e.g.. Bay Area), has a 
specific capability (e.g., Web ATM), or any combination of the three. Today we use market 
class to determine the set of graphics that the ATM will receive. With the Web ATM, the 
market class specifies the ads that will play when there is no customer session. 

To define the ad association, the administrator must have added the market class to the 
Customer Profile table (see section B.3). Then the administrator uses the same linkage 
capability referenced in section B.5 to assign a set of ads to the market class. 

7. Pilot Advertisement Configuration 

The following matrix represents the advertising components that will be built based upon 
Customer Profile. In order to keep the administration of ads manageable in the Pilot 
timeframe, only one targeted ad per customer is recommended. 



Customer Profile Ad Type Ad Name Backgrounds 



Non-Specific 


• Attract 

• Teaser 


• Banking Center Ad 

• Teaser] 


Background 1 


• Proprietary Default 

• Basic 

• Plus 

• Associates 


• Targeted 

• Closer 


• Target! 

• Closer! 


Background! 


• Premier 

• Private 


• Targeted 

• Teaser 

• Closer 


• Target2 

• Teaser2 

• Closer2 


Background2 


Targeted Acquirer 


• Targeted 

• Closer 


• Targets 

• Closer2 


Background ! 


Acquirer Default 


• Targeted 

• Teaser 

• Closer 


• Target4 

• Teaser3 

• Closer! 


Background! 



C. System Management 

The implementation of the Web ATM implies that additional system and network management 
functions must be developed to ensure the availability of the ATM features and functions. Two 
operational areas are affected: 

• System Monitoring 

• Software and Content Distribution 
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1. System Monitoring 

Three components are affected by the Web ATM project that require enhancements to the 
monitoring tools: 

• ATM - the Web ATM will need to alert operations whenever there is a loss of service by 
the Web Server. This will require a new unsolicited event that will be sent by the ATM 
to the Base24 Device Handler 

• Web Server - the new Web and Application server components must also be monitored 
by the system. These components include the Web Server pathway, the server processes, 
and the TCP/IP communication layer. The monitoring systems must be able to recognize 
and act on these new events. 

• MQ - the Web Server will access mainframe services via the Message Queuing (MQ) 
interface. Operations will need to monitor these processes and communication links. 

2. Softw^are Distribution 

The Web ATM requires that certain software be resident on the ATM itself. In addition, 
there will be graphic files present on the ATM to avoid the performance impact of moving 
large files across the network during customer interaction. We will develop the processes and 
procedures to distribute both software and graphical files to the Web ATMs. At a minimum, 
we must be able to: 

• Maintain the inventory of software and graphics resident at each ATM 

• Automatically distribute and install new software and graphics to one, a group, or all 
Web ATMs 

• Back-out any changes at the Web ATM 

• Status the Web ATM concerning the current complement of software and graphics 
file versions 
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F. Test Data Requirements 

L States to be tested 

2. Data Requirement 1 

a) Data Type Description 

b) Requirement 

3. Data Requirement 2... 

G. Cycle Requirements 

1. Cycle Requirement 1 

a) Cycle Description 

b) Requirement 

2. Cycle Requirement 2... 

H. Testing Risks 

1. Testing Risk 1 

2. Testing Risk 2... 
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1 



V. ASSUMPTIONS 



Assumption Confirmed by 



Financial transaction receipts will print with current Model 
standards. 




Web ATM components will function with Model Base24 
Device Handlers. 




No software changes will be required to the Base24 Driving 
platform for Pilot Phase I other than: the TCP/IP Protocol 
support, the handling of new unsolicited ATM status messages 
about problems concerning Web access, and the translation of 
status bytes. 
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VI. OPEN ISSUES 





Issue 


Status 


Responsibility 


Target 
Date 


1. 


Is it required for the Web Pilot that ATM 
cameras take photos of transactions (from the 
data stream) and superimpose them on the photo 
of the customer? (Do cameras in the East do this 
now?) If so, changes from multiple camera 
vendors are required to implement this because 
the current system does not support TCP/IP. 
Resolution: Avoid usine cameras until a 


Closed 


Pete Abowd 


09/30/99 


corporate direction is established. 


2. 


Will rear-load ATMs will be included in the Pilot 
mix? If so, one needs to be installed in the 
development lab. 
Resolution; Yes 


Closed 


Pete Abowd 


09/30/99 


3. 


What denominations is the pilot web ATM 
required to support? 
Resolution: $20 


Closed 


Greg Borchardt 


09/30/99 


4. 


Which transactions will unconverted Bank of 
America customers receive, and what targeted 
ads (if any)? 
Resolution: Acquirer 


Closed 


Greg Borchardt 


09/30/99 


J* 


Should the Language and Pin Entry screens for 
Web Pilot be merged (as the examples in this 
document currently show) or split? 
Resolution: Merged 






OQ/l S/00 
yjyi 1 jiyy 


6. 


The "Another Transaction?" screen features the 
new Web information request functions in 
addition to the traditional yes/no keys. Should 
those new functions be included on that screen? 
Resolution: Keep the Web Additonal Services 


Closed 


Greg Borchardt 


09/30/99 


but re-desien the screen fonnat so that it is more 


clear to the customer what to -do next. 


7. 


What to do with the Message the Bank and 
Check Reorder functions for the Pilot? 
Traditional Model ATM may remove it from the 
menu — should Web ATM do the same? Or, 
Deluxe needs to be contacted to explore the 
possibility of electronically transmitting check 
reorders from the ATM directly to the company. 
Can this be done in time for the Pilot? 
Resolution: Since Check Reorder cannot be 


Closed 


Greg Borchardt, 
Anne Zeller 


09/30/99 


automated within the Phase 1 timeframe, and 
since it. alon^ with Message to Bank, will 
probably be removed from traditional ATM 
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menus, it should be removed from the Web menu 








as well (as long as it is also removed from the 
tradjtiojiaJjii.enMsX 


Q 
0. 


Should we use the Track 1 Name in the screen 
dialogue? The accuracy of the name field in 
Track 1 data for both proprietary and acquired 
cards needs to be investigated. Additionally, are 
there security reasons why Customer Name 

Status: Don Schonder states that the Track 1 




Borchardt 


00 A 0/00 


name is not verv accurate. Also, the Bank's 


"Privacy Expert!Lrecommends usin^ onlvJhe 


first name on the ATM screen. More discussion 
on which name and where is needed. 


9. 


Can the infrastructure be built to send specific 
customers individual messages in time for the 
Pilot? Can the IBD messaging technique be 
used? 

Resolution: No 


Closed 


Anne Zeller 


09/30/99 


10. 


What is the set of advertising for the Pilot (the 
Pilot Advertisement Configuration matrix in the 
functional specification may be used as a starting 
point)? 

Status: Targeted for completion in October 




Greg Borchardt, 
Faith Tucker 


09/30/99 


11. 


Who will be the "Advertisement 
Administrator(s)", the main user(s) of the 
Advertisement subsystem? 
Resolution: Faith Tucker has aereed to assume 


Closed 


Greg Borchardt, 
Faith Tucker 


11/15/99 


this role for the pilot. 


12. 


The Hardware requirements to support the Web 

pilot must be specified. 

Resolution: Done- and distributed by e-mail. 


Closed 


Greg Borchardt 


09/30/99 


13. 


Are there any MIS reports desired from the Web 




Borchardt Tucker 


10/31/99 


transaction loes or Advertising database? 


Status: Bill Nash win followup. 






14. 


Can the settlement mechanism for items sold at 
the ATM (i.e., phone time) be put into olace for 


Closed 


Zeller 


09/30/99 


Pilot Phase 1? 

Resolution: No — will be in a future release. 
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VII. INDIVIDUALS INVOLVED 



Area of Responsibility 


Individual Name 


Phone 


Sign-off 


ATM / Debit Card Project Management 


Nash, Bill 


925-675-3945 




ATM Architecture 


Dwyer, Larry 


925-692-8298 




ATM Architecture 


Nicoll, Bruce 


704-386-9456 




ATM Architecture 


Zeller, Anne 


925-675-1809 


* 


ATM Management and Development 


Borchardt, Greg 


415-436-5173 




ATM Management and Development 


Raymond, Bill 


415-436-5161 


* 


ATM Management and Development 


Tucker, Faith 


316-261-4179 




ATM/POS/Monitoring Systems 


Clark, Adam 


704-388-5943 




ATM/POS/Monitoring Systems 


Evans, Roy 


925-675-2706 




ATM/POS/Monitoring Systems 


Fei, Calvin 


925-675-2619 




ATM/POS/Monitoring Systems 


Gilbert, Mark 


404-331-8130 


* 


ATM/POS/Monitoring Systems 


Givot, Marty 


925-675-3223 




ATM/POS/Monitoring Systems 


Jacobs, George 


925-675-2217 




ATM/POS/Monitoring Systems 


Liuzzi, Frank 


704-386-7269 




ATM/POS/Monitoring Systems 


Martin, Marsha 


505-282-5124 




ATM/POS/Monitoring Systems 


Nelson, Ann 


925-675-3671 




ATM/POS/Monitoring Systems 


Schwappach, Michele 


505-282-4229 




ATM/POS/Monitoring Systems 


Stockton, Mark 


925-675-3301 




ATM/POS/Monitoring Systems 


Weatherford, Pam 


704-386-9306 




ATM Debit Card Operations 


Abowd, Peter 


415-241-4335 


* 


Bank Workflow/Product Integration 
(Service Broker Systems) 


r^flmnhpl 1 Xprrv 

V^Cll 1 1 L/L/W' 1 1 , I VI 1 Y 


704-386-3307 
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